Instead of necessarily using AvailabilityArbitration, we could just pick a scope that's authorized and not the correct one. I'd probably add a list_authorized_scopes() method to DSSInstanceResource that returns the values in its self._auth_adapter.scopes, then pick one of those that isn't the correct scope and isn't a blank scope (if such an option exists).

nit: It's probably worth clarifying which scopes are mandatory (just utm.strategic_coordination, I think) and which will provide additional test coverage

I'm not sure I understand the distinction wrt authorization -- A2.7.2(7) mentions "authorization" rather than authentication and it seems like we're covering authorization here (e.g., reject for incorrect scope). I would expect authentication in the DSS scope to be mostly limited to checking the signature of the access token, though authentication is one portion of authorization (DSS should generally not authorized unauthenticated users, for instance)

The comment is meant to convey that the scenario is not checking situations where a client that does not own an entity tries to mutate or delete it.

Indeed, checking for scopes is already a step towards authorization checks, and I will reword the comment:

Note that although the wording for A2.7.2(7) contains authorization, I did not interpret it as meaning we need to check all authorization scenarios:

Tests must demonstrate that access to the interfaces is denied when a properly formed authorization with an appropriate authorization scope is not provided.

Here the authorization is something that must be provided by the client (in my assumption), so I interpret that the specification uses that word to refer to the token, not to something that the DSS needs to do. (Authorization checks are or will be properly covered by other scenarios, so an inaccurate interpretation here should have no impact on overall coverage)

This will throw a KeyError if the empty string is not present in available_scopes

Replaced .remove with discard

This will throw a KeyError if the scope isn't in available_scopes. We haven't yet made the call to get_instance, so we don't yet know if this scope is actually available or not. After calling get_instance, either we'll have a working DSSInstance and can be confident the required scopes are available, or else a MissingResourceError would have aborted execution.

Ah, indeed. get_instance is now called at the earliest possible time in the constructor.

In general, we want automated tests to be repeatable. Pseudorandomness is ok, but we should generally initialize any pseudorandom generator with a fixed seed so test results are repeatable. In this case, we probably shouldn't pick an item randomly, but instead select whatever item is "first".

This line indicates that self._dss will only ever make calls with scopes, which only contains StrategicCoordination at this point. It seems like we should wait to call this until we know what scopes we want to use (i.e., ~line 84)

This is not doing anything here because scopes was already used above to get_instance. get_instance should be called after we have figured out all our scopes.

get_authorized_scopes can be called any time (no need to call get_instance first), and we want to use it to figure out what scopes we need in order to be able to call get_instance with the appropriate information.